> This program uses "calc.c," the program mentioned by Timothy Newsham > in an earlier message. The program has been modified slightly so > that it gives better results (it would occasionally fail to locate > the offset of a config given a buggy sendmail. The fix is to force a > sync() after it generates a coredump.) Actually, that's not the right fix. The problem is that... > gencore() > { [...fork, exec sendmail, send it signal 11...] > } > main(argc,argv) > char **argv; > int argc; > { > unsigned int ConfFile,tTdvect,off; > > gencore(); > sync(); /* grr. */ > tTdvect = find("ZZZZZZZZ", "core"); > ConfFile = find(argv[1], "core"); ...that nothing is done to ensure that the coredump is finished by the time find() opens it to look for the magic pattern. gencore() returns only moments after sending the signal. You're just lucky that on the systems you tried, the sync() either blocks waiting for the coredump to complete or takes long enough for it to complete. The right fix is for gencore() to do a wait() on the child process, to wait for it to go away after completing the coredump. ObBugQ: Anyone know just what the SPARC integer divide bug is? I've got copies of the relevant kernel .o files both before and after the patch, but haven't gotten around to disassembling and uncompiling enough to figure out what's wrong yet. der Mouse mouse@collatz.mcrcim.mcgill.edu